perf: build std string encoders and escapers in linear time - #699

A set of std functions built their output with s = s + piece inside a loop. Each append recopies the whole string accumulated so far, so the work grew quadratically with the input. This is the same shape #686 fixed in base64; the worst availability offenders (redis, http2, the io buffered readers) were fixed in #687/#689/#695, and this cleans up the char-by-char remainder. Each site now accumulates through a byte buffer or a list join and materializes the string once at the end.

The network-facing hot paths are the ones that matter most: url percent encode/decode (every query param, form body, and CSRF token), json string unescaping inside parse, grpc-message percent coding, and template <% for %> rendering. The rest are std primitives a lot of higher-level code sits on: hex, base32, and base58 encoding; the log, metrics, and html escapers; strings swap_case/reverse/repeat; text fold/sanitize/from_chars/from_code_points; regex replace_all; term strip; collections join_with; yaml quoted-scalar decoding; and config json string reading.

While surveying I found and fixed several sites beyond the ticket's list, all the same shape: grpc percent_encode/percent_decode, yaml decode_double_quoted/decode_single_quoted/repeat_newlines, strings swap_case/reverse/repeat_text, text from_chars/from_code_points/sanitize/fold, regex replace_all, term strip, collections join_with, metrics normalize_metric_name, and config config_json_read_string. No non-std code was touched.

Two decode paths (url decode, grpc percent_decode) accumulate through a List[String] join rather than a byte buffer on purpose: a decoded byte can be invalid UTF-8 (%ff), which a buffer round-trip through UTF-8 validation would reject, so the list preserves the existing behavior exactly.

what was tested

Output is byte-identical. For every fixed site I ran a checksum sweep at n = 0, 1, 2, 3, 17, 255, 1000, 4096, 65537 against the old and new std and diffed: identical at every size. The encoders and escapers were also anchored to external oracles, not self-round-tripping:

• url percent encode/decode vs python urllib.parse — matched at every size
• json string unescape (through parse, surrogate pairs included) vs python json.loads — matched
• hex vs python binascii.hexlify over all 256 byte values — matched
• base32 / base32hex vs the RFC 4648 vectors; base58 vs the bitcoin-alphabet vector — matched

A new golden test, tests/cases/test_string_builder_linearity.pith, locks the user-visible encoders (url, json, hex, base32, base58, html, template) to their oracle-verified output.

The curve flattens. Interleaved A/B wall-time (min of 3 trials) at 4x size steps, so the shape is what to read — quadratic should step ~16x, linear ~4x:

A 200k-iteration leak smoke over the rewritten builders held steady at ~600 MB peak RSS on both old and new std (no per-call leak from the parts lists or buffers).

Suites, one at a time: run-regressions-only 342/0, check-invalid-only 44/0 (after rebuilding self-host/pith_main), run-examples-self-only 121/121. No doc or example describes these functions' internal accumulation strategy, so nothing there needed updating.